home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Oct 89 / Z0076-Eiffel-Oct89 < prev    next >
Encoding:
Text File  |  1989-10-13  |  4.3 KB  |  92 lines  |  [TEXT/GEOL]
  1. Item    0459583                         13-Oct-89        11:13
  2.  
  3. From:   D1282                           Power Up,PRT
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. Sub:    Eiffel
  8.  
  9. Attn:  MacApp.Tech$
  10. SentBy: James Plamondon
  11. Date   10/13/89
  12. Subject    Eiffel
  13. From   James Plamondon
  14. To  MacApp.Tech$
  15.  
  16. Reply to:  Eiffel
  17. Dear Mr. Lander,
  18.  
  19. You inquired (in your recent link ré Eiffel) about the MPW implementation of
  20. Eiffel, and about other matters.
  21.  
  22. As to the MPW version of Eiffel I’ve been talking about: it being written by
  23. (or at least for) Interactive Software Engineering, Bertrand Meyer’s company,
  24. which is located at 270 Storke Road #7, Goleta, CA  93117 (USA), phone number
  25. (805) 685-1006.  (I don’t know their link address, if any.)  The person to
  26. speak to concerning the Mac version is either Meyer himself, his wife Anna, or
  27. Mr. Todd Wilkinson.  It was originally scheduled for a November ‘89 release; I
  28. think few of us will be surprised to hear that this date has slipped.  Release
  29. is now scheduled for January of ‘90.  I have inquired as to the price, but
  30. evidently the price has either not yet been decided or is not yet firm enough
  31. to annouce — although the amount of $800 was mentioned.
  32.  
  33. As to Meyer being hard to deal with, I have heard rumours to that effect,
  34. also.  But this is a common, and perhaps necessary, characteristic of those
  35. visionaries — need I specifically mention Steve Jobs? — who are driven to buck
  36. the trend to make their vision become reality.  Besides — the guy’s French.
  37.  
  38. I agree with you (at least until someone presents a convincing argument to the
  39. contrary) that renaming seems both useful and powerful.  I’ve asked M.
  40. Muys-Vasovic to elaborate on his statement, “renaming is terrible,” but I as
  41. yet have had no response (but then, not all of us live on the net).
  42.  
  43. I also agree that the CASE statement is just a shorthand for a bunch of IF
  44. statements, and that it is not strictly necessary — but then again, it is an
  45. awfully useful shorthand.  I would like to see it introduced to Eiffel.
  46.  
  47. I am fascinated by the argument, mentioned by M. Muys-Vasovic, that assertions
  48. should not be a part of the Eiffel language, since they can (in C, for
  49. example) be simulated by macros and/or function calls.  I admit that this is
  50. true; however, I am not convinced that this argument is enough to make me
  51. agree that assertions are unnecessary.
  52.  
  53. In RatFor, a pre-processor for FORTRAN, one can write structured FORTRAN, but
  54. this does not make FORTRAN as palatable as (say) Pascal, in which the
  55. structuring is supported directly.  On could even make the argument (although
  56. I certainly wouldn’t) that hearing people say “Ok, that’s a neat language
  57. feature, but I can do the same thing in X” means that X is on its last legs.
  58. After all, anything any high-level language can do, I can do in Assembler, or
  59. even machine code — but I wouldn’t want to.  In writing my Assembler code, I
  60. wouldn’t have any of the built-in features that make my job easier — that’s
  61. all the high-level language gives me.  So, if features that make my job easier
  62. are all a language is for, then I want the best features I can have — and
  63. assertions seem like an excellent example of such a feature.  Of course they
  64. can be simulated in lower-level languages — but then the lower-level language
  65. would also have to simulate ‘short’ (the automatic class documentation tool),
  66. proper inheritance of assertions, loop variants and invariants (I love those),
  67. and class invariants.  If you’re going to go to all that work just to simulate
  68. one basic feature of Eiffel, why not do half the wortk and get all the
  69. features by just switching to Eiffel?
  70.  
  71. Thanks for your response to my link.  This is the kind of thing MacApp.Tech$
  72. is perfect for — it’s got the highest concentration of people knowlegeable
  73. about OOP of any discussion group around.  And, although this does not relate
  74. immediately to MacApp, it’s only a heartbeat away:  if a programmer is already
  75. considering going to C++, she might as well consider going to Eiffel instead
  76. — don’t you think?
  77.  
  78. As always, I’m willing to be convinced that I’m wrong in any of my above
  79. statements — please, let me know if you have a compelling argument.
  80.  
  81. Yours,
  82.  
  83. James Plamondon
  84. Software Engineer
  85. PowerUp! Software
  86. 2929 Campus Drive, Suite 300
  87. San Mateo, CA  94403
  88. (415) 345-5900 x351
  89. AppleLink: D1282
  90. CompuServe: 71230,734
  91.  
  92.